1. Technical Field
The present invention is directed to a method and apparatus for managing a dynamic alias page table. Specifically, the present invention is directed to a mechanism for dynamically determining if a new page of memory is needed for storing alias page table entries and pinning entries in a hardware page table associated with such a new page in order to avoid faults on the alias page table.
2. Description of Related Art
In operating systems it is desirable to support a mechanism for shared memory, i.e. memory that can be addressed by multiple processes but which is a single block of memory. Shared memory allows one process to write data that can be read by a different process. Though there is a single physical frame per page of this shared memory, there will be as many virtual addresses that map to the physical frame as there are processes that have attached the shared memory.
In the AIX operating system, an alias page table (APT) is used to manage these aliases for a physical address. Because AIX uses an inverted software page table (that is, it has a single entry per physical frame that describes a virtual frame mapped to that physical frame), when more than one virtual address maps to the same physical address, a separate table is necessary to record the extra mappings, or aliases.
The hardware on which the AIX operating system runs supports a hardware page frame table that is a large cache of the virtual-to-physical translations in the system. It is a hashed table with fixed size hash buckets, so it is possible that, when the hash buckets become full, there are translations that exist in software that are not in hardware. When a process attempts access to a virtual address that is not in the hardware page table but is in software managed tables, this is termed a reload fault, as the hardware translation must be reloaded from the software. The hardware supports the pinning of entries in the hardware table. These pinned entries will not be removed by the hardware when a hash group becomes full, and thus a reload fault on a pinned entry cannot happen.
The alias page table is used to manage the translations of the various virtual addresses to physical addresses and provide for resolving reload faults on alias addresses at interrupt level. Typically, the memory regions needed to maintain the alias page table are allocated when the virtual memory manager is initialized. Thus, there is a fixed amount of memory that is provided for storing alias information even if the alias page table currently is empty or underutilized.
With the ability to have aliases in hardware, a special table for most software aliasing is not needed except for shared memory regions being used for input/output operations. The memory used to fully describe the aliases is large and is not pinned. Reload faults on aliased memory can be serviced from these descriptions without a special table when interrupts are enabled. However, reload faults on aliases cannot be serviced at interrupt level with the standard structures that describe the aliases; hence the need for an alias page table which records the minimum information about the aliases necessary for servicing reload faults. Because shared memory is not often used for input/output operations, the alias page table will typically be empty or underutilized. As a result, there is allocated memory that goes unused and thus, system resources are wasted. Furthermore, since the alias page table is used to resolve reload faults, no reload faults can be allowed on the table itself.
Thus, it would be beneficial to have a method and apparatus for managing a dynamic alias page table in which alias page table entries are created dynamically and reload faults on the alias page table itself are handled.